1. Field of the Invention
This invention relates to enterprise information systems, and more particularly to a system and method for providing a metadata-aware Enterprise Application Integration (EAI) framework for an application server environment.
2. Description of the Related Art
The Java 2 Enterprise Edition (J2EE) provides a standard platform for developing various flavors of applications using Java Server Page (JSP), Servlets and Enterprise JavaBeans (EJBs). This standard platform may be used to implement Mission critical enterprise applications using Java & J2EE. The declarative deployment model of J2EE to specify transactional, secure semantics is very well received and accepted. A Java system implementation that adheres to the standard platform specifications of J2EE may be described as a ‘container’ or application server in which J2EE applications execute. Enterprises may desire to have their J2EE applications interact with Enterprise Information Systems (EIS) and any of various applications including proprietary, standalone and in-house/partner applications that are external to the container. The container may be viewed as a front-end system, and the external applications or EIS as back-end systems. Front-end and back-end are terms used to characterize program interfaces and services relative to the initial user of these interfaces and services. (The “user” may be a human being or a program.) A front-end is one that users interact with directly. A back-end serves indirectly in support of the front-end services. As an example, a front-end system might interface directly with users and forward requests to a remotely located back-end system to get requested data or perform a requested service. A backend system (e.g. EIS system) may be any of various types of systems that provide one or more services including database systems, other application servers, and systems capable of performing business functions not provided by the front-end system.
The Java 2 Enterprise Edition Connector Architecture (J2EE CA) specification specifies a mechanism by which a conforming Enterprise Information System (EIS) connector may be embedded in a container (such as a web/application server). The services of the connector are available to applications executing within that container. J2EE CA specifies a required contract between the connector and the container for managing resource pooling, transactions and security. J2EE CA also specifies a Common Client Interface (CCI) for client interaction with the connector, which the connector may choose to implement.
The (optional) J2EE CA specified Common Client Interface (CCI) attempts to define a unified interaction model across disparate EISs. A connector is a low-level protocol bridge to a specific EIS. A J2EE CA-compliant connector that chooses to implement CCI exposes only this basic ‘protocol-level’ functionality to the caller. The connector functionality is semantically equivalent to the functionality of the low-level client library that will typically be embedded inside the connector. Specifically:                high-level functions explicitly defined in the EIS may be mapped to one call to the EIS, but the data representation will typically be untyped, not reflective of implied data structure, and extremely prone to inducing hard-to-detect caller programming errors.        high-level functions implicitly defined in the EIS will typically map to multiple low-level calls to the EIS, thereby multiplying the problem outlined in above.        
As such CCI by itself exposes no semantics relating to high-level functions which may be explicitly/implicitly defined on the EIS. If a J2EE CA connector were to model interaction with high-level functions (implicitly/explicitly defined) on the EIS, this would impose a requirement that the connector be aware and capable of executing such high-level function calls made directly on it. Which means that either the connector would be hardcoded for a fixed set of high-level functions, or that the connector developer would be responsible for implementing a general-purpose scheme for mapping an extendable set of high-level function calls to the internally-available low-level client-library API. The J2EE CA framework provides no means for the application developer to define/declare, discover, or introspect high-level functions as callable entities which map to a sequence of low-level calls to the specific EIS connector.
J2EE CA specifies an optional data representation for input/output, which may be reused across EIS. However, the data representation specified by J2EE CA is non-standard in the industry sense, and is thus unlikely to be adopted by connector providers. Moreover, even if the data representation specified by J2EE CA were adopted, this representation is not at all amenable to being transformed/mapped via declarative means such as XSL (Extensible Stylesheet Language (XSL) Translations).
Other prior art frameworks for uniformly modeling interaction with high-level functions (implicitly or explicitly defined) across disparate EIS also require that high-level function calls be hardcoded on the connector.
Java 2 Enterprise Edition Connector Architecture (J2EE CA) solves one level of problems by allowing a connector to an external EIS to reside within a container. J2EE CA provides a connector to only the low-level functions of the EIS. The J2EE CA specification does not create a design space for modeling high-level functions for a J2EE CA connector. In J2EE CA, the only way to model high-level functions is by hardcoding the functions in the connector. This model is not suitable to modeling high-level business functions that are not known at the time the connector is implemented. As a result, a user has to know how to sequence low-level functions together to perform a desired high-level function. Thus, J2EE CA presents a low level of abstraction to the developer. For ease of use, developers would like to see a higher level of abstraction than is provided by J2EE CA. The EAI framework as described herein provides this higher level of abstraction on top of J2EE CA connectors.
A J2EE CA Service Provider Interface (SPI) implementation may assist the connector developer in developing and deploying J2EE CA-compliant connectors. The J2EE CA SPI implementation may adhere to connection pooling, transaction management and security management interfaces of J2EE CA. By doing so, off the shelf J2EE CA-compliant connectors may be plugged in, and the connector-provided interaction API may be exposed, as is. Since the connector specification does not mandate CCI to be the client interaction API, this is sufficient to be J2EE CA compliant. The J2EE CA SPI implementation may allocate, match and deallocate connections from the connection pool(s). The J2EE CA SPI implementation may also perform caller principal-to-resource principal mapping. The J2EE CA SPI implementation may also enlist/de-list the EIS connections with the transaction managers based on a J2EE application transaction scope and connector-declared transaction participating ability. The J2EE CA SPI implementation may also allow a container (e.g. an Enterprise JavaBeans (EJB) container) to perform connection sharing and other optimizations.
As an example of using a J2EE CA connector, consider a banking enterprise system including an SAP system that hosts one or more high-level functions which are “unknown” or not exposed to the banking enterprise system. The high-level functions provide access to a database of information hosted by the SAP system to which the banking enterprise wants to provide access for its employees and customers. A J2EE CA connector will give the programmer the ability to talk to the SAP system, but is not aware of, and does not provide access to, the high-level functions on the SAP system. These high-level functions reside within the SAP system and are not explicit in terms of being directly visible to any client library API. J2EE CA does not provide a design space by which these functions can be modeled and dropped into a connector.
It may be desirable to expose at least some high-level functions of back-end systems such as EIS as loosely-coupled services. A loosely-coupled service is a service that is external to the container serving as a front-end. It may also be desirable to expose these high-level functions to tightly-coupled and loosely-coupled clients. A tightly-coupled client is a client that executes in the same container as the connector. A loosely-coupled client is one that is external to the container. However, a J2EE CA connector is usable only by tightly coupled clients because a sequence of low-level calls must happen on the same connection to the EIS in order to perform a high-level action in a consistent manner. A sequence of low-level calls are related by state in the sense that the sequence of low-level calls must happen on the same connection to the EIS in order to perform a high-level action in a consistent manner. If these low level calls originate from a loosely-coupled client (e.g. through a web service), then the calls cannot be associated by state because web service technologies are stateless. For example, if low-level calls L1, L2, L3 are made using a remote web service, it is not guaranteed that the calls go across the same connection. There may be guaranteed sequence/order, but the association of state will not be guaranteed. Thus, it is desirable to provide a framework in which high-level calls consisting of a sequence of low-level calls may be made to an EIS loosely-coupled to a container via a connector from a client loosely coupled to the container via a service such as a web service.